Walkie-talkie type services have long proved popular amongst users who wish to communicate brief messages quickly between one another. Conventionally, such services have been provided by two-way portable radios which utilise a dedicated part of the radio spectrum, but which only allow users to communicate with a small group of pre-selected users who utilise similar terminals and who are within range of the relatively short operating range of the radios. More recently, so-called Push-To-Talk (PTT) services have been introduced into the United States which piggy-back on the existing cellular telephone infrastructure. However, these PTT services have been proprietary in nature and have not allowed users to communicate between different operator networks.
In an attempt to broaden the use of walkie-talkie type services, an industry grouping known as the Open Mobile Alliance (www.openmobilealliance.org) has been established with the aim of standardising suitable protocols which will allow inter-network operability for Walkie-Talkie services offered over cellular networks. The service established by the various standards is known as Push-to-talk over Cellular (PoC). PoC proposes that associated speech data will be transported over a packet switched access network. In the case of GSM and UMTS, this will be the general packet radio service (GPRS) or 3G access network. In other network architectures, analogous packet switched access networks will be utilised for transporting talk data. Push to Talk services may also be offered over circuit switched access networks, although this is not the preferred option.
The Push to talk over Cellular (PoC) system is typically implemented on GSM/GPRS/3G networks and which makes use of the IP Multimedia Subsystem (IMS) standardised by the 3rd Generation Partnership Project to facilitate the introduction of advanced data services into cellular networks, and in particular of real-time multimedia services. The IMS relies upon the Session Initiation Protocol (SIP) which has been defined by the Internet Engineering Task Force (IETF) for the setting up and control of multimedia IP-based sessions. A PoC Server is located within the IMS or is attached thereto, and implements the functionality for setting up and controlling PoC Sessions.
The “Group” is a concept standardised in OMA and provided as a general feature to OMA services including, but not limited to, PoC. Groups can be made applicable to one or more services, or services can be excluded from being used by a Group. A Group can be configured to include a set of pre-defined members, and is specified by an XML “Group Document”. The Group document can hold a list of members that specifies membership to the Group. A Group Document can also specify a policy for the Group, i.e. a set of pre-defined rules that indicate what authority is associated with a membership. A group document is maintained by an XML Document Management Server (XDMS). Groups, membership to Groups, and policies for Groups (including sharing of a Group between services) can be configured by management operations supported by the OMA XML Document Management (XDM) enabler.
When creating a new Group it is possible to automatically advertise the existence of the Group to the Group members. It is also possible to advertise to existing members when a newcomer is added to an already existing Group (or a member is removed). This is realised using the standardised feature known as “Extended Group Advertisement”, as specified in the OMA XDM 2.0 release, where the Shared Group XDMS that stores the Group document, also creates the advertisement message and sends it towards each member. The feature can be used by any service for which the Group is defined. Whether an automatic advertisement shall be sent or not is configured for the Group. [NB. The term “Shared” when referring to the Group XDMS and also to the Policy XDMS is not used in later OMA releases, but it will be understood that when referring to the Shared Group XDMS and Shared Policy XDMS in this document, those later releases are also encompassed.]
It is also possible for the creator of a PoC Group to advertise the members of the new Group from a user terminal, or “User Equipment”, such as a mobile terminal, equipped with a PoC Client using the feature “Group Advertisement”, as specified in OMA PoC V1.0 release. Both this advertisement feature and the Group XDMS advertisement feature mentioned above use the PoC Server to route the advertisement message to Group members. The advantage of utilising these features is that members can be made aware of the existence of a group before the group is called into any session or other communication.
As well as pre-defined groups, Group members can also be defined temporarily, i.e. the membership to the group exists only for the duration of the communication session. These are referred to as ad-hoc Groups. For such groups no Group Advertisement can be sent out on beforehand to signal the existence of the group, and no check of membership policy can be done before the group is called into any session. Such temporary groups can for example be created as 1-1 sessions or 1-to-many, e.g. by a PoC User providing a list of peer Users invited to the ad-hoc PoC Group session, as specified in OMA PoC V1.0 release. [In PoC standard specifications members in a PoC session are denominated “Participants”.]
One mechanism for creating pre-defined and ad-hoc groups is to use criteria under which membership is valid. These criteria are associated with the information available about each User, e.g. being located in the London area and being ‘available’ for communication. The set of members matching the criteria may change dynamically depending on User behaviour. In PoC V2.1 release there is a feature for dynamic PoC Groups that use criteria for defining groups. The criteria can be defined ad-hoc by a User who invites other Users or can be pre-defined for a Group, and can be applied to a PoC session either only at session establishment or also during the whole session. These dynamic PoC sessions will then be similar to ordinary PoC sessions, but in this case the Participants in the PoC session will only be those matching the criteria, i.e. Participants can be added or removed dynamically during a session based on the criteria.
The OMA CBUS (Condition Based URIs Selection) enabler provides a signalling interface to other OMA services (e.g. PoC) that enables them, from an input consisting of a set of criteria and a list of Users, to find those Users in the list that match the criteria. This interface is used, e.g. by a PoC server, to find which Users to invite to a PoC session.
Members in a Group can also be defined by means of a search for Users using a set of search criteria. In this case the Group itself is pre-defined but the list of members in the Group document is empty, as specified in Requirement Document for PoC V2.1. The search criteria will then determine which Users that can become members of the Group. This search feature is intended to be supported in a future release of OMA CBUS V1.0, as specified in Requirement Document for CBUS V1.0, extending the CBUS enabler to allow searching for matching Users based on a set of criteria but without having any list of Users to select from.
A User can define and store his or her own access policy, as specified in PoC V1.0 release and in XDM 2.0 release, to define the rules under which incoming calls and messages are accepted by the User. The rules are stored in a Shared Policy XDMS, and are private and not revealed by the system to other Users. In particular, a User can specify whether a peer User is allowed to invite him/her or not, e.g. by assigning the peer User's PoC address to the condition element <identity>, together with an actions element <allow-reject-invite> set to ‘true’ in his User Access policy document. The document is XML-based and conforms to the common policy framework as specified in IETF RFC4745 [Common Policy: A Document Format for Expressing Privacy Preferences”, H. Schulzrinne et al, February 2007]. Being a member of a Group does not mean that the member User has to give up his User Access policy as an individual. Members within a Group may still have their own privacy policy and apply it against the other members of the Group.
The current state of OMA PoC is set out in Release 1.0. The specification for PoC Release 2.0 and PoC release 2.1 is on-going. PoC Release 2.0 will extend PoC to include multimedia and not just speech, while PoC release 2.1 will enhance the PoC session establishment and media type handling. The current state of OMA XDM is set out in Release 1.1. The specification for XDM Release 2.0 and 2.1 is on-going. Both XDM Release 2.0 and 2.1 will extend XDM to include extended features for Group management and support of PoC. The current state of OMA CBUS is set out in Release 1.0 whose specification is ongoing.
The User access policy rules, or indeed any other rule associated with the User, do not allow a User to accept or reject proposed membership of a Group. The existing User access policy document is a limited mechanism as the User can only specify the policy based on inviting identity and not for example on the nature/type of group. Although the identity (e.g. which the User wishes to block) can be a pre-defined Group identity, the User does not know the identity of the Group before it has been created. Even if the User can include the Group identity in a list of rejected Groups once the Group is created, he can still not prevent becoming a member of the Group.
A PoC Group can be configured to include a set of pre-defined members. For such a pre-defined Group the members can invite themselves to, or be invited to, a PoC session for the Group. Who will be invited to a PoC session may depend on an inviting member's choice. In these simple scenarios there is not a privacy problem because the (invited) User can always refrain from inviting himself or can reject an invitation, e.g. if the invited user does not trust the inviting user. There may however be scenarios in which a User would prefer not to be invited, not necessarily because of who is the inviting User, but because of the reason why he is invited (e.g. as a result of a search for users based upon certain criteria).
When creating a Group and sending the advertisement message to the Group members, it may happen that a member is not available to receive the message, e.g. currently not registered. A User can thus become a member of a Group without being aware of it. In any case, even if the member is registered at the moment of advertising a new Group, it is already too late to reject the membership. The User does not have the possibility to give his consent to or reject the membership. This may be perceived as an intrusion that will make the User reluctant to share his User profile information with the network and other Users.
PoC currently provides a User access policy that is enforced for Users at their Participating PoC servers. Such a policy is applied in real time to incoming session invitations. A User may, for example, set a policy to block invitations for which the originating call identity is anonymous.